建設的フィードバックの5つのバリエーション
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
個人が他者からの視点に気づいたり、改善箇所を知ることができる建設的フィードバック。
その内容にはいくつかの種類があります。個別の内容と必要な対応についてまとめます。
1. 改善につながる正しい建設的フィードバック
フィードバック内容が適切で、改善に繋がる内容です。
例えば
- タイポの指摘
- プログラミングのコードの臭いに対するリファクタリングの提案
などがあります。
一番扱いやすい建設的フィードバックで、必要なタイミングで時間を作って対応するのみです。
2. 一見正しくみえるが対応をしないほうがいい建設的フィードバック
フィードバック内容を単発でみると適切で、改善に繋がりそうにみえるが
- ROI を加味すると、取り組むことによるデメリットが上回る
- 現状の優先度を加味すると、しばらくの間は優先して取り組むような対象ではない
というようなものです。
対応は不要です。
3. 改善につながるかわからない建設的フィードバック
フィードバックとして受け取った内容が問題点の解決に効果があるかないかわからない場合です。
この場合は、試す価値がありそうなら試すとよいでしょう。
4. 好みの領域の建設的フィードバック
フィードバックとして受け取った内容は好みの問題で、特に正解が存在しないような場合です。
例えば、テキストチャットに関して1回で長い文章で伝えるのと。同じ内容を小分けにして伝えるのとどちらがいいかは好みが分かれ、明確な正解が存在しません。
この場合は、自分の好みと合えば受け入れればいいですし、合わなければスルーでよいでしょう。
5. 誤りの建設的フィードバック
フィードバックとして受け取った内容が明らかに誤っている場合です。
対応は不要です。
フィードバック元への対応
対応したケース
相手のフィードバックのおかげで自身を改善できた場合、その結果を感謝とともに相手に知らせるとよいでしょう。
これはフィードバック内容に対するポジティブ・フィードバックです。自分のフィードバックが役に立ったかどうかがわかると次のフィードバックの質を向上することにもつながります。
対応しないケース
フィードバックに対応しない事を決める場合、その後の対応は2つにわかれます。
フィードバックをくれた相手との間に「フィードバックを受け取った相手がそれをどう扱おうと自由。相手の選択を尊重する」という認識統一ができていれば、特に細かい事情を知らせる必要はなく、対応しないだけで問題ありません。ただ、対応しないことを知らせてはいけないわけではないので、必要だと思ったら知らせても問題ありません。
一方で、フィードバックをしたからには相手は受け入れる必要がある、と考えている相手の場合は、なぜそのフィードバックに対する改善を実施しないかを説明する必要があります。また、フィードバックをした相手その説明を「言い訳」と解釈せずに聞く必要があります。もし、言い訳と断定することを続けていると、受け取ったフィードバックをスルーしにくくなり、有効ではないフィードバックを嫌々受け入れざるを得なくなる可能性があります。
根本的にはフィードバックを送る側のフィードバックスキルを上げる必要があります。
まとめ
建設的なフィードバックにどのようなバリエーションがあり、どのような対応をするかについてまとめました。
こういった内容を踏まえると、改めてフィードバック相手に改善対応を常に必須で求めることのリスクがわかります。あなたが常に100%正しい建設的フィードバックのみをできるのなら話は別ですが、おそらくそういった方はかなりレアです。
